The present invention relates to updating software applications and more particularly a method and a device for managing software updates of a set of equipment of a system such as an aircraft system, allowing in particular automatic reloading of an initial configuration following an error in updating one or more of the devices.
Generally, each aircraft manufactured is delivered to an airline in a particular configuration. However, since a technical solution may change over time, aircraft manufacturers generally implement improvement procedures according to which hardware and/or software elements are replaced by others.
Each part of the aircraft, mechanical, electronic or software, is identified by an invariant code, known as the FIN (Functional Item Number), denoting the function of the part and its location. Moreover, each of said parts comprises an identification number, known as the PNR (Part Number Reference), which identifies the technical solution applied to the mechanical, electronic or software part concerned to perform the function for which it is intended. A PNR can also be associated with a group of parts forming a functional assembly, also known as a Constituent Assembly, such as a landing gear assembly. A PNR is an identifier that is variable over time depending on the manufacturer and the version.
Thus, during the lifetime of an aircraft an element having the reference PNR1 may be replaced by an element having the reference PNR2, said elements having the same FIN code. The replacement of an element having a code PNR1 by another having a code PNR2 takes place through a configuration management process in which the individual element changed is known as a modification (MOD). The technical features of the change are described in a Technical Repercussion Sheet.
Manufacturers generally offer airlines the opportunity to benefit from improvements to the aircraft of which they have taken delivery. MODs are then applied to aircraft that have already been delivered according to the instructions in a Service Bulletin (SB). These bulletins are official documents used for notifying an airline of the modifications to be made to one or more aircraft that it is operating. They are generally produced by the manufacturers. However, they can also be issued by their suppliers. In this case, they must be validated by the manufacturer.
Like the MOD, a SB describes the state before application of the SB, for example use of the element having the code PNR1, and the state after application, for example use of the element having the code PNR2, the technical improvements provided by the new elements, and a description of the work to be carried out to replace the elements involved, for example the duration and the number and category of personnel necessary for application of the SB and the procedures to be applied.
According to a particular embodiment, described in particular in Patent Application FR 2 943 152, the SB is delivered in electronic form (known as an eSB). This makes it possible to automate certain equipment software update tasks, without changing hardware. Such equipment is generally updated using a central configuration management system, known as DLCS (Data Loading and Configuration System), which allows direct loading from an aircraft.
A significant feature of an eSB executed by a DLCS is the automatic reproduction of operations carried out by a maintenance operative. Said operations are, for example, as follows:                verifying the initial configuration of the equipment (typically avionics calculators) covered by the eSB, known as PRE-MOD, and, if applicable, verifying the configuration of other equipment in order to verify compatibility constraints (verification of mixability);        selecting the software elements for loading depending on the PRE-MOD configuration of the items of equipment;        verifying the completeness of the software elements for loading (typically the set comprising the new software elements and the software elements to be reloaded);        launching the loading of the software elements, possibly requiring adherence to a loading order for a given target item of equipment and for target items of equipment themselves (thus, for example, AFDX™ (Avionic Full DupleX) switches must generally be loaded in a particular order to avoid losing the AFDX™ network during loading);        verifying the configuration of the equipment after loading has been completed, known as POST-MOD; and        displaying explanatory messages to a maintenance operative giving results of the type “OK” and “NOK” for each step, instructions and help information.        
However, although such a solution is often effective, it can be improved. When one or more equipment updates fail, the intervention of a maintenance operative is necessary to determine if the update must be retried or not and, if applicable, to reconfigure the system to its initial state (PRE-MOD).
Thus, by way of illustration, considering three calculators C1, C2, C3 and C4 each comprising software elements L1, L2, L3 and L4 in their version n and requiring migration to a version n+1, it is assumed that the update of calculators C1 and C2 takes place correctly, as well as the update of software element L1 on calculator C3, but that an error occurs during the update of software element L2 on calculator C3.
In this case, the maintenance operative assumes control of the update process and retries the update of software element L2 on calculator C3. After several unsuccessful attempts, the operative decides to reconfigure the system to its initial version (n) so as not to immobilize the aircraft for too long. To this end, he must reload software elements L1, L2, L3 and L4, in their version n, onto calculators C1 and C2 and reload software elements L1 and L2, in their version n, onto calculator C3.
Such procedures are time-consuming and have a significant impact on aircraft availability.
It is noted here that the loss of time and the possibility of operator error are increased, in particular, by the number of software elements for loading, the number of target items of equipment concerned and the moment at which the error occurs (if the update fails during the update of the first software element of the first target item of equipment, less effort is required to restore the original configuration than if the failure occurs on the last software element of the last target item of equipment).
It is also noted that if the type of equipment on which an update fails has not thus far experienced any particular update problems, the maintenance operative would tend to retry loading the software element regardless of the type of error encountered. If, on the other hand, the type of equipment on which an update fails has regularly experienced update problems, the operative, as a result of his experience, would tend not to check the error messages generated by the loading protocol and risk deciding directly to return to the initial configuration, possibly missing the opportunity of successful installation if he had retried the update.
The invention makes it possible to solve at least one of the problems set out above.